Part of: #77600

What

Refactors the wp_user_taxonomy REST surface and its write-time sanitization model. Stops exposing the raw post_content JSON string over REST and replaces it with a typed config object plus a top-level object_type array. Concentrates server-side declaration in one place: the controller class is the single source of truth for the schema, and a thin wp_insert_post_data filter routes writes through rest_sanitize_value_from_schema() against that schema. Adds filterable post-type membership via ?object_type[]= and wires the corresponding isAny filter into the listing UI.

How

The previous shape stored JSON in post_content and forced both client and consumers to parse strings. That made the typed schema (additionalProperties: false, label allowlist, types) impossible to enforce at the REST layer, made _fields=config.labels.singular_name queries useless, and required the client to JSON-stringify on every save.

The new shape pushes structure into the schema and centralizes write-time sanitization:

• The REST controller (WP_REST_User_Taxonomies_Controller_Gutenberg) declares the canonical config schema via a static get_config_schema() method, used both by get_item_schema() and by the post-type-scoped sanitizer. The schema closes over typed booleans, length-bounded label strings (maxLength: 200) and description (maxLength: 1000), with additionalProperties: false at every object level so unknown keys are rejected with 400. object_type carries maxItems: 50 and a ^[a-z0-9_-]{1,20}$ per-item pattern.
• The sanitizer (gutenberg_user_taxonomy_sanitize_config) is a thin wrapper around WP core's rest_sanitize_value_from_schema() against get_config_schema(). It applies one extra layer of HTML/control-char stripping (sanitize_text_field for labels, sanitize_textarea_field for description) because rest_sanitize_value_from_schema only casts string types, it doesn't strip.
• The sanitizer is hooked to wp_insert_post_data, scoped by post_type === 'wp_user_taxonomy'. wp_insert_post_data is the last filter before the row is written, so the re-encode is what lands in the database. Stored JSON is encoded with JSON_UNESCAPED_SLASHES | JSON_HEX_TAG | JSON_HEX_AMP, so the final stored bytes carry no live <, >, or & — any subsequent pass through kses (on later updates or display) sees an inert string. Empty object-shaped positions stay {} (not []) via an explicit normalize_config_for_encode() helper that casts them to stdClass, leaving room to add array-typed schema fields later without JSON_FORCE_OBJECT silently coercing them.
• Invalid JSON submitted via wp_insert_post() for the CPT is normalized to a canonical marker-only payload rather than persisted as-is — a hedge against a stray read path surfacing arbitrary bytes.
• The filter is unconditional — taxonomy config isn't HTML and shouldn't carry scripts even for users with unfiltered_html. Imports, XML-RPC, and REST writes all pass through wp_insert_post() and therefore through the filter.
• A storage-only marker (isUserTaxonomyConfigJSON) is embedded in stored bytes. It's deliberately not in the REST schema (stripped on read), and isn't load-bearing today — kept as a forward-compat anchor for a content-only fallback sanitizer if a future write path bypasses wp_insert_post_data.

Server changes

• REST controller WP_REST_User_Taxonomies_Controller_Gutenberg. Extends WP_REST_Posts_Controller because user taxonomies are stored as posts of the private wp_user_taxonomy CPT, not as WP terms. Owns the schema (get_item_schema() consumes get_config_schema() and get_allowed_label_keys() — the canonical declaration site). Adds an object_type[] collection param backed by meta_query IN. prepare_item_for_database validates slug shape (^[a-z0-9_-]{1,32}$) and uniqueness (returns WP_Error on collision) and JSON-encodes the request config for post_content via normalize_config_for_encode(); config is replaced atomically when the param is present, with no in-config partial-update support. create_item and update_item are overridden to write _wp_user_taxonomy_object_type post meta and re-prepare the response so the just-written meta surfaces in the response body — same re-prepare pattern as WP_REST_Attachments_Controller.
• Post-type-scoped sanitizer gutenberg_filter_user_taxonomy_post_content on wp_insert_post_data. Acts on wp_user_taxonomy posts; falls through to a canonical empty payload for invalid JSON. Delegates structural sanitization to WP_REST_User_Taxonomies_Controller_Gutenberg::get_config_schema() via rest_sanitize_value_from_schema(), then re-encodes with JSON_UNESCAPED_SLASHES | JSON_HEX_TAG | JSON_HEX_AMP.
• object_type moved to multi-value post meta (_wp_user_taxonomy_object_type). Stored separately from the JSON config so listings can filter on it via meta_query (a single serialized array would force fragile LIKE queries). Underscore-prefixed for protected-meta semantics. Surfaced over REST as the typed top-level object_type field.

Client changes

• TaxonomyRecord and TaxonomyFormData are now typed (config: StoredConfig, object_type: string[]). toFormData / serializeForSave are thin translators between wire and form shape — no more JSON parse/stringify on every save.
• useObjectTypeField enables the post-types column filter (filterBy: { operators: [ 'isAny' ] }).
• routes/taxonomies/stage.tsx translates the object_type view filter into the REST query arg.

Tests

PHPUnit coverage for the controller in phpunit/experimental/content-types/class-wp-rest-user-taxonomies-controller-gutenberg-test.php — 28 tests / 88 assertions, including schema strictness on unknown keys (top-level + config.labels), marker key absent from the REST response, drafts skipped by gutenberg_register_user_defined_taxonomies, invalid object_type slug → 400, byte-stable round-trip, and the invalid-JSON normalization hedge.

Notes

Taxonomies created before this PR aren't migrated. Their attached post types lived inside the JSON config in post_content; the new code reads them from the _wp_user_taxonomy_object_type post meta, which those older records don't have. To get them showing post types again in the UI, delete and recreate them. (The feature is still experimental and pre-launch, so no production data is at risk.)

Testing instructions

1. Enable the Content types: manage custom taxonomies experiment.
2. Go to Settings → Taxonomies and play around with adding and editing taxonomies.
3. Also test the post types filter

Use of AI Tools

Opus 4.7 with direction, changes and review